STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/GRAPHICS/@FALCON/VIEWERS/FLICTC/DEUTSCH/CHANGES.TXT

Text File | 1995-04-23 | 22.3 KB | 438 lines

Änderungen am FLIC-Player FLICTCxx.PRG

23.4.95
Version 4.7.1
Auf Anregung von Alexander Clauss lä₧t sich das Double-Buffering nun während
des Abspielens über die Taste <d> ab- und wieder einschalten, es mu₧ dazu aber
beim Start des Abspielvorgangs aktiv gewesen sein, nachträgliche Aktivierung
ist (noch?) nicht möglich.
In der Abspielstatistik wird nun auch die sinnvoll verbrauchte CPU-Zeit
angezeigt, d.h. die reine Abspielzeit ohne Synchronisation mit Timer oder
Vsync.

22.4.95
Das Blitter-TOS 1.02 feiert seinen 8.Geburtstag ;)

19.4.95
Version 4.7.0 (nicht veröffentlicht)
Speichermodell umgestellt, der Player sollte nun auch im FastRAM laufen,
ganz nebenbei dürfte die Abspielgeschwindigkeit auf Rechnern mit FastRAM
deutlich höher sein. Den Stack habe ich wieder auf 8K verkleinert.
Mit Schrecken mu₧te ich feststellen, da₧ der Player bis jetzt immer den
ganzen freien Speicher kassiert hat, nun wird nur noch soviel Speicher
alloziert, wie wirklich benötigt wird.

7.4.95
Version 4.6.0 (nicht veröffentlicht)
alle Programme mit neuer Compilerversion neukompiliert, ein paar Bytes
kürzer und hoffentlich um einige Bugs ärmer :)

2.4.95
Version 4.6.0
Ein paar kleine Erweiterungen eingeführt: die Bildhelligkeit lä₧t sich nun
über den Schalter <-c=x> frei einstellen, <x> ist ein Prozentwert, unter
Umständen werde ich dieses Feature auch während des Abspielvorgangs zur
Verfügung stellen, leider wäre dann immer ein komplettes Redraw nötig :(
(Deltakompression!). Ferner kann die Animation jederzeit mit <Enter> oder
<Return> angehalten, und mit einer beliebigen Taste fortgesetzt werden.
Als Erweiterung des Quietmodus gibt es nun noch den Keyboard-Off-Modus
(-k=1), in diesem Modus reagiert der Player nur noch auf die Maustasten,
die Tastatur wird dann nicht mehr abgefragt (es ist blöd, wenn der Benutzer
in irgendwelchen Zwischensequenzen rumpfuschen kann)

22.3.95
Version 4.5.5
Optimierung der 68020-FLI_LC2/SS2-Dekompression, statt zwei Wortzugriffen
findet im Byterun nun ein Langwortzugriff statt, leider hatte das
bei meinen FLCs praktisch keine Auswirkungen auf die Wiedergabe-
geschwindigkeit (<1% :( ), aber im Extremfall (sich bewegende Rechtecke
o.ä.) sollten >30% drin sein ...

20.3.95
Version 4.5.4 (nicht veröffentlicht)
Bei der Headeranzeige wird nun statt 0 auch wirklich wieder das Magic
ausgegeben, weiterhin habe ich den Stack von 4K auf 32K vergrö₧ert.

19.3.95
Version 4.5.3 (nicht veröffentlicht)
Ab sofort wird Double-Buffering nur noch auf Falcon-Videohardware aus-
geführt (auf Grafikkarten hat es sowieso nicht funktioniert)

2.3.95
Version 4.5.2
Die Geschwindigkeit beim Double-Buffering ist jetzt je nach Animation und
Rechner um bis zu 30% höher geworden, der Player wartete vorher auch bei
Double-Buffering noch auf den Vsync (so dieser aktiv war), was ziemlich
überflüssig war und nur Zeit kostete :)
Als weitere Neuerung gibt es nun einen Quietmodus (-q=1): In diesem Modus
macht der Player keine Ausgaben auf den Bildschirm (au₧er der Animation
natürlich) und wartet nach Ende des Abspielens auch nicht auf Tastendruck.
Damit sollte es nun möglich sein den Player aus eigenen Programmen zum
Abspielen von FLIs/FLCs aufzurufen, ich warte auf die ersten Spiele mit
tollen Filmsequenzen :) Soll ein Programm, welches den FLICTC verwendet
veröffentlicht werden, verlange ich die Zusendung eines Belegexemplars
und bei Shareware zusätzlich eine Beteiligung von 10-20% an den
Registrierungseinnahmen. Bei kommerzieller Software sind die Nutzungs-
bedingungen von Fall zu Fall auszuhandeln.

2.3.95
Version 4.5.1 (nicht veröffentlicht)
Die automatische Erkennung des Grafikmodus (Intel oder Motorola) ist nun
abschaltbar, d.h. falls der Schalter -I=0 oder -I=1 auftaucht, unterbleibt
der Versuch den Modus selbst zu ermitteln. Au₧erdem wird nun bei der Auf-
lösungsumschaltung und beim Double-Buffering die Logbase fest gelassen, d.h.
Fehlermeldungen landen auf dem "richtigen" Bildschirm in der richtigen
Auflösung. Wird eine Animation über einen Mausklick abgebrochen, wird nun
auf das Loslassen der Taste gewartet.

1.3.95
Version 4.5.0 (nicht veröffentlicht)
Auf Anregung von Torsten Lang habe ich die Hardwareanforderungen etwas ab-
geschwächt, FLICTC sollte nun auch (wieder) auf normalen STs mit MC68000
Prozessor laufen (leider mangels ST mit HiColor-Grafikkarte nicht getestet),
HiColor-Grafik ist aber weiterhin zwingend erforderlich. Je nach CPU-Typ
(oder besser Cookie) verwendet der Player entweder 68000 oder 68020-Code :)
Grafikkarten, die im Intelwortformat (tolles Wort :) ) arbeiten werden nun
automatisch erkannt, der -I=0/1 Schalter ist damit überflüssig, ich werde
ihn demnächst entfernen (you have been warned).
Ferner ist ein kleiner Fehler bei der Anzeige der Header-Information von
bei FLIs behoben: Der angezeigte Wert war um den Faktor 2.85 zu hoch.

6.2.95
Version 4.4.4
Gerade dachte ich, ich wäre fertig und schon habe ich wieder einen Bug-Report
in der Post (und wieder vielen Dank an Daniel Hedberg), Ihr la₧t mir wohl gar
nichts durchgehen, oder?
Unbekannte Schalter in der Kommandozeile führten in eine Endlosschleife statt
ins Desktop - nur ein Reset half noch :( , behoben.
Au₧erdem ist nun über -S=<x> die Grenze für das intelligente Double-Buffering
frei wählbar, sinnvoll auf normalen Falcons dürfte x=10..x=14 sein, bei auf-
gebohrten Rechnern x=14..x=18.

4.2.95
Version 4.4.3 (nicht veröffentlicht)
Die neue Assembler-FLI_Brun-Routine ist fertig, war nicht sonderlich schwer,
sogar die Condition-Codes für die Sprünge waren auf Anhieb richtig, Sachen
gibt's :)
Nun steht auch in der deutschen Anleitung, da₧ man mit der Taste "0" wieder
die Ursprungswerte einstellen kann ...

2.2.95
Version 4.4.2 (nicht veröffentlicht)
Es war noch ein Fehler in der FLI_Brun Dekompression, d.h. der Player konnte
beim Entpacken des ersten Bildes in FLC-Animationen (und nur dort) ziemlich
übel abstürzen (Dank an Daniel Hedberg :) )
Meine Routine war nämlich auf korrekte Angaben in den Paketzählern angewiesen
(und funktionierte bei all meinen FLCs - schmoll) - dummerweise müssen die
Paketzähler beim FLC-Format nicht sinnvoll initialisiert werden, das Zeilen-
ende mu₧ hier anhand der Länge der entpackten Daten erkannt werden. Die erste
Version einer geänderten FLI_Brun-Routine läuft schon in BASIC, in den
nächsten Tagen werde ich sie in Assembler übersetzen...
Ach ja: es gibt nun eine anständige Fehlerbehandlung, d.h. falls ein Fehler
auftritt wird ggf erst die Auflösung zurückgeschaltet und dann eine Fehler-
meldung ausgegeben. Nun kann man sogar lesen was kaputt ist :)

31.1.95
Version 4.4.1 (nicht veröffentlicht)
Interne Struktur wieder verknotet und dem Double-Buffering ein wenig
Intelligenz (ein Widerspruch in sich ,) ) verpa₧t: bei -D=2 wird nun bei
Animationen, die laut Header nur mit bis zu 14 fps laufen sollen, das DB
eingeschaltet, bei schnelleren Animationen wird es abgeschaltet (eigentlich
naheliegend, oder?). Dies ist übrigens die neue Standardeinstellung.

Januar 95
Version 4.4.0 (nicht veröffentlicht)
Ich habe den Code ein wenig aufgeräumt und die interne Struktur ein wenig
entknotet, als angenehmer Nebeneffekt klappt die Auflösungsumschaltung nun
auch auf RGB/TV (tat sie vorher leider nur halb: hin klappte, zurück nicht :(
Dank an Daniel Hedberg!). Habe ich vergessen zu erwähnen, da₧ es einen neuen
Schalter (und natürlich auch eine neue Funktion) gibt? Ab sofort wird Double-
Buffering unterstützt, d.h. es werden dann drei Bildschirmseiten benutzt,
wobei die erste das vorletzte Bild enthält, die zweite das letzte Bild und auf
der dritten verdeckt das nächste Bild aufgebaut wird, damit reduziert sich
Geflacker und Geruckel auf Null :) , soweit zu den guten Nachrichten ...
die schlechte Nachricht ist, das das Double-Buffering quälend langsam ist,
d.h. auf einem 16MHz-Falcon funktioniert das Ganze bis ca. 14 fps ohne
Geschwindigkeitsverlust (wobei dann schon ca. 80-90% der Rechenzeit auf das
Umkopieren von Bildschirmen entfallen :( ), bei mehr als 14 fps wird das DB
dann zum Bremsklotz, hier stö₧t der Falcon an seine Grenzen (hat jemand
vielleicht FastRAM oder eine Speicherkarte mit 0 Waitstates?). In späteren
Versionen werde ich das DB vielleicht noch so ändern, da₧ die Bildschirmseiten
nicht kopiert, sondern dreimal entpackt werden, dürfte meistens schneller sein
als komplettes Kopieren ... der zuständige Schalterbeamte ist übrigens -D=0/1

15.12.94
Version 4.3.2
Heute morgen fand ich in meiner Mail eine kurze Nachricht von Christian
Krüger wegen des Fehlers beim Umschalten in HiColor auf RGB/TV:
die Breite in RGB-Overscan beträgt nicht 368 sondern 384 Pixel, das
Bild erschien daher völlig verzerrt :-(
Nun sollte die Umschaltung aber auch auf RGB/TV funktionieren :-)
(na, war das schnelle Arbeit?!)

14.12.94
Version 4.3.1 (nicht veröffentlicht)
Da sich der Player nun über die Tastatur steuern lä₧t, lag es irgendwie doch
nah auch andere Optionen über die Tastatur ändern zu können:
<t> schaltet die Synchronisation mit dem 200Hz-Timer ein bzw. aus (-t=...)
<v> schaltet die Synchronisation mit dem Vsync ein bzw. aus (-v=...)
<l> Warten nach letztem Bild ein bzw. aus (-L=...)
<0> setzt alles auf die Anfangswerte zurück
Au₧erdem wird nun der Bildschirmspeicher bei der "-z"-Option gelöscht, das
hatte ich leider übersehen; fiel auch nicht auf, weil das OS sowieso immer
gelöschte Speicherblöcke verteilt (kann sich aber ändern!)
Die Auflösungsumschaltung in RGB funktioniert leider noch nicht korrekt und
ist deshalb auf RGB erstmal nicht mehr verfügbar (ich arbeite aber daran!)

11.12.94
Version 4.3.0 (nicht veröffentlicht)
Einige kleine Nettigkeiten eingeführt, so ist es nun z.B. möglich die Ab-
spielgeschwindigkeit im Betrieb über die Tasten <+> (schneller) ,<->
(langsamer)und <0> (normal, bzw. externe Vorgabe) zu beeinflussen, einfach
mal ausprobieren! Diese Erweiterung hat zur Konsequenz, das der Player nun
nur noch auf die Maustasten und die Leertaste reagiert.
Au₧erdem gibt's mal wieder ein paar neue Schalter:
-I=1 schaltet in einen Intelwort-orientierten Grafikmodus (z.B. für TT's mit
     VGA-Karte, funktioniert aber nur in HiColor, und auch dort nur vielleicht)
-d=1 Debugmodus für eben diesen Zweck, auf TT's stürzt der Player scheinbar
     nach Programmende ab ... (sch... Compiler!)
-L=1 don't wait on Last frame, überspringt die Warteschleife nach dem letzten
     Bild einer Animation: in manchen FLIs sind das erste und das letzte Bild
     identisch, dies führt zu einem störenden ruckeln. Dieser Schalter bringt
     Abhilfe, die Animation läuft nun "runder".

21.11.94
Version 4.2.0
Auf vielfachen Wunsch kann der Player nun auch von selbst die Auflösung
wechseln (-z=1) - auch bei externen Videoerweiterungen. An dieser Stelle
vielen Dank an Christian "chrisker" Krüger der mir die entsprechende Routine
zur Verfügung stellte.
Weiterhin sind noch ein paar kleine Verbesserungen abgefallen. Unter anderem
wird nun über den CookieJar der Prozessortyp und die Videohardware getestet,
die Darstellungsroutinen laufen erst ab 68020 und das direkte Umschalten der
Auflösung funktioniert auch nur mit der Falcon-Videohardware. Ich weise an
dieser Stelle noch einmal darauf hin, da₧ ich *KEINE* Verantwortung für even-
tuelle Beschädigungen an Hard- oder Software übernehme, die Benutzung des
FLICTCxx erfolgt auf eigene Gefahr.
Ferner lä₧t sich die Abspielgeschwindigkeit über einen neuen Schalter
(-s=<x>) nun frei einstellen. Die Angabe erfolgt in Bilder/Sekunde.
In der Datei SPEED.TXT habe ich als Referenzauflösung nun die normale Desktop-
Auflösung 320x240x65536 mit 60Hz gewählt, die Angaben sind nun leichter ver-
gleichbar.

04.11.94
Version 4.1.0
So, nun kommt der Player auch mit Dateien klar, die eine falsche (zu kleine,
z.B. ohne Header und Ringframe wie bei 7J7.FLI) Längenangabe im Header
stehen haben. Dieser "Fehler" hat mich einige Nerven gekostet, gewohnheits-
mä₧ig hatte ich den Fehler bei mir gesucht, nur lag er leider eben nicht bei
mir. Ich kam erst auf die Ursache (falsche Länge im FLIC-Header), nachdem in
einer auf das Nötigste reduzierten Version des Players (ohne Anzeige, etc)
nach dem Umstieg von Fread() auf BLOAD plötzlich alles funktionierte...
Sollte der Player eine abweichende Grö₧e feststellen, passiert folgendes:
-Datei ist grö₧er als im Header eingetragen:
 Es wird intern mit der realen Dateigrö₧e gearbeitet.
 Ist die Info-Seite aktiviert, wird eine Warnung ausgegeben.
-Datei ist kleiner als im Header angegeben:
 Es erscheint eine Abfrage, ob das Programm beendet werden, oder ob die
 Datei trotzdem abgespielt werden soll.
Ferner ist das uralte work-around (ein Byte weiter vorne nochmal versuchen)
endlich überflüssig geworden, innerhalb eines FLICs scheinen die Grö₧enan-
gaben nämlich zuverlässig zu sein...

28.10.94
Version 4.0.0 (ehemals 3.6.0 ...)
Es klappt! Es klappt! Der Player kann nun auch FLCs abspielen!
Mein Dank gebührt Alexander Clauss, der mir mit Informationen über das
FLC-Format aushelfen konnte; der c't-Artikel war in dieser Hinsicht leider
nicht sehr ergiebig. Momentan gibt es noch Probleme mit vereinzelten FLIs
(z.B. 7J7.FLI), bei denen der Player das Ende nicht richtig erkennt und
einfach abbricht, trotzdem werde ich diese Version veröffentlichen, da nur
wenige FLIs betroffen sind und der Fehler auch schon in allen anderen
Versionen steckte.
Auslöser für den Entschlu₧ nun doch FLCs abzuspielen, war übrigens die
Erkenntnis, da₧ man auf einem 68030 in nur 6 Takten aus einem Intel-Wort
ein Motorola-Wort machen kann. Wie? - Ganz einfach: ein ror.w #8,D0 erledigt
das Gewünschte, zu allem Überflu₧ kann der '030 auch Worte von ungeraden
Adressen lesen, so da₧ man mit zwei Befehlen ein Intel-Wort aus dem Speicher
holen und in das Motorola-Format wandeln kann!
Au₧erdem müssen nur sehr wenig Worte verarbeitet werden, das Meiste lä₧t
sich über Byte-Operationen erschlagen...

20.10.94
Version 3.5.3 (immer noch)
am Player selbst keine Veränderungen, allerdings ist die englische
Anleitung nochmal leicht überarbeitet worden (Dank an Lars Weinrich).
Au₧erdem habe ich einen einfachen Benchmark (HYDRAMRK.TOS) beigelegt, der
die CPU- und Busperformance mi₧t, nützlich um die Busbelastung durch die
Videoauflösung zu ermitteln. Benutzer von Auflösungserweiterungen können
sich zum Beispiel eine Auflösung 320x200 in HiColor, 60Hz, SINGLESCAN
basteln, allerdings natürlich auf eigene Gefahr (Monitordaten beachten!),
mein Rechner erreicht in einer solchen Auflösung (bei 20 Mhz) 117% im Ver-
gleich zu ST-Hoch auf einem 16MHz-Falken, neuer Rekord bei 40MHz und
<HANDS.FLI> 688.8 fps ...

06.10.94
Version 3.5.3
Es wird nun überprüft, ob die abzuspielende Datei wirklich ein FLI ist,
nicht überall wo FLI hintersteht ist auch FLI davor (oder so ähnlich).
In Version 4.0 werden wohl FLCs unterstützt werden, allerdings weiter nur
in HiColor (ich habe nämlich einige 320x200 FLCs entdeckt - es gibt sie
also doch!). Au₧erdem existiert nun die Datei SPEED.TXT in der die er-
reichten Maximalgeschwindigkeiten einiger FLIs auf meinem Falcon angegeben
sind.

04.10.94
Version 3.5.2 (nicht veröffentlicht)
Im Fehlerfall wurde die Eingabedatei nicht geschlossen, nun behoben.

02.10.94
Version 3.5.1 (nicht veröffentlicht)
Tja, nobody's perfect, ein alter, längst tot geglaubter Bekannter war in
Version 3.5.0 wieder aufgetaucht (bei FAN.FLI und MOUSE.FLI):
<skipping unknown chunk type ...>, trat allerdings nur beim Spielen
von Platte auf, ich habe ihm (hoffentlich!) endgültig Hausverbot erteilt, das
mysteriöse work around aus Version 3.1 ist hiermit rehabilitiert ...
Der freie Speicher wird nun auf der Statusseite (-i=1) mit angezeigt.
Ich überlege für zukünftige Versionen die Speicherverwaltung aus Version
3.4.x zusätzlich wieder einzuführen, da bei sehr komplexen Animationen mit
sehr gro₧en Einzelbildern die Abspielgeschwindigkeit beim jetzigen Verfahren
stark einbricht (die Festplatte ist halt kein D-Zug... wie wär's mit 'ner
RAM-Disk?!), ein Festplattencache kann den Effekt aber mildern ...

01.10.94
Version 3.5.0 (nicht veröffentlicht)
Die Speicherverwaltung ist noch einmal komplett umgekrempelt worden, FLIs
die nicht komplett in den Speicher passen werden jetzt Bild für Bild von
der Platte gespielt, die Daten für das nächste Bild werden wenn möglich in
der Wartezeit für das nächste Bild geladen, die Animationen wirken nun viel
flüssiger, allerdings ist der Betrieb von Diskette dadurch ziemlich unmöglich
geworden, aber andererseits sollte jeder Falcon genug Speicher haben, um eine
Datei von Diskette komplett laden zu können (oder gibt es nun doch 1MB-
Falcons?)
Au₧erdem ist der Player mit eingeschalteter VBL-Synchronisation nochmal ein
ganzes Stück schneller geworden (bis zu 20%) (eine Zeilenvertauschung bei den
Timing-Schleifen macht's möglich), nun lassen sich auch bei eingeschalteter
Vsync-Option meistens 95-105% der Originalgeschwindigkeit errreichen!
Ach ja, der Player ist sogar 1kB im Vergleich zur Version 3.4.1 kürzer
geworden ...
Der <-m=xxxxx> Schalter aus Version 3.4.1 existiert übrigens weiter,
vielleicht kann's irgend jemand gebrauchen und au₧erdem kann man so auch
ohne übergro₧e FLIs zu besitzen (so wie ich) der Platte mal ein bi₧chen
Stre₧ machen ...

27.9.94
Version 3.4.1 (nicht veröffentlicht)
neuer Schalter (-m=xxxxx) eingeführt, der den Player veranlasst nur
xxxxx kB RAM zu benutzen, dazu mu₧te die Commandine-Auswertung komplett
überarbeitet werden, nach Au₧en hat sich allerdings nichts geändert.

27.9.94
Version 3.4.0 (nicht veröfentlicht)
Der Player kann nun Dateien, die nicht in den Speicher passen direkt von
Diskette oder Festplatte abspielen, wobei das freie RAM als Puffer genutzt
wird. Im Gegensatz zu anderen Playern werden Dateien die komplett ins RAM
passen auch weiterhin ganz aus dem RAM abgespielt.
Im Moment lädt der Player immer so viel von dem FLI, wie gerade in den
Speicher pa₧t, spielt den Puffer bis kurz vor das Ende ab und lädt dann
nach. Dieses Vorgehen bringt im Schnitt die höchste Abspielrate, allerdings
hakt die Darstellung bei gro₧em Puffer und sehr langen FLIs ein wenig, da
unter Umständen mehrere Megabytes nachgeladen werden müssen ...
In der nächsten Version wird es einen Schalter geben, der den Player anweist
nur eine gewisse Menge Speicher zu verwenden; au₧erdem denke ich über FLC-
Unterstützung nach, wei₧ jemand ob es auch FLCs in Auflösungen kleiner als
640x480 gibt (z.B. 320x200 oder 480*400) ?

26.9.94
Version 3.3.3 (nicht veröffentlicht)
Dateien, die nicht in den Speicher passen, werden nun auch nicht mehr
geladen. Dieser peinliche Fehler steckte in allen bisherigen Versionen
und konnte zu einem Totalabsturz führen...

25.9.94
Version 3.3.2 (nicht veröffentlicht)
Es gab wohl doch noch einen(?) Fehler im Player (nobody's perfect,
vielen Dank an Alexander Clauss!). Manchmal wurde der Chunkheader nicht
korrekt gefunden, das (sowieso nicht besonders elegante) work around aus
Version 3.1 war halt noch nicht ganz das Gelbe vom Ei, glücklicherweise
gibt es eine ziemlich einfache Lösung (manchmal sieht man den Wald vor
lauter Bäumen nicht - nochmal vielen Dank an Alexander...), jetzt sollten
sich alle FLIs abspielen lassen, die auch in den Speicher passen...
(mal schauen, wer mich diesmal eines besseren belehrt?!?)

8.9.94
Version 3.3.1
Für den Grünanteil werden die in HiColor vorhandenen 6 Bit nun auch aus-
genutzt, vorher lag das niederwertigste Grünbit brach (d.h. auf Null).

6.9.94
Version 3.3
Schalter zur Anzeige der Header-Information eingebaut, bisher zeigte der
Player den Header beim Start kurz an und begann gleich darauf mit dem
Abspielen, sehr unschön, aber wie gesagt Vergangenheit.
Ein paar kosmetische Verschönerungen, um den Film wird nun ein Zelluloid-
streifen dargestellt, ist allerdings nur bei ausreichend hoher Auflösung
(ab 400x270) voll sichtbar, macht sich aber ganz gut (Eigenlob!).

4.9.94
Version 3.2 (immer noch)
Englische Kurzanleitung gestrickt: quick and dirty, aber besser als
nix, konstruktive(!) Kritik erlaubt.

13.8.94
Version 3.2
Umstellung auf 68020-Code, das bringt nun je nach Animation bis zu
15% mehr Geschwindigkeit!
Um diesen Unterschied messen zu können wurde ein neuer Schalter
(-t=0/1) eingeführt, der den Player anweist die vorgegebene Abspiel-
geschwindigkeit komplett zu ignorieren, neue Spitzengeschwindigkeit
bei Aufruf mit -t=0 -v=0 HANDS.FLI : 608 fps (Falcon, 40MHz CPU,
20MHz Bus, 320x200, 66.3Hz).
Abfrage auf korrekte Auflösung eingebaut, vorher schmi₧ der Player
Bomben, wenn er in einer Auflösung mit weniger als 65536 Farben
gestartet wurde.

12.8.94
Version 3.1 ist nun (hoffentlich) fehlerfrei, letzte Probleme mit
wenigen Animationen beseitigt (FAN.FLI, MOUSE.FLI), irgendwie scheint
der Header bei diesen FLIs ein Byte früher zu beginnen (noch in den
Daten vom letzten Chunk?), mit dem Effekt, das mein Player nur die
zweite Hälfte vom Magic fand und mit einer Fehlermeldung abbrach,
das gehört nun der Vergangenheit an, sollte das Magic mal nicht
stimmen, macht der Player einfach einen zweiten Versuch ein Byte weiter
vorne... Ziemlich primitiv, aber es funktioniert, wer eine bessere Idee
hat möge sich bitte melden...

Version 3.0
Endlich sind die Assemblerroutinen fertig, in so einem FLI lauern
doch diverse Fallen beim Umstieg von einer Hochsprache (mit FOR-
Schleifen) nach Assembler (mit DBRA), die Paketanzahl und die Anzahl
der zu setzenden Pixel kann nämlich Null sein, mit entsprechend fatalen
Folgen in den Assembler-Routinen, aus 0.w wird durch Abziehen von 1.w
(wegen DBRA) dann 65535.w, und nichts stimmt mehr... Davon hatte die
c't nichts erwähnt (schmoll...)
Ferner kann der Player nun endlich auch Animationen loopen und
den Vsync ignorieren.

Version 2.0
Diese Version ist immer noch in Basic, allerdings wertet sie die Farben
korrekt aus und zeigt die Animation nun in HiColor an, durch Umstieg
von DRAW auf WPOKE Geschwindigkeitsteigerung um mehrere hundert Prozent,
das Compilat spielt Animationen mit 10 fps (frames per second) ab,
hat allerdings noch Probleme mit diversen FLIs (FAN.FLI, MOUSE.FLI)

Version 1.0
Der erste Player, noch immer in Basic, kann inzwischen schon die
ersten Animationen abspielen (BIRDY.FLI), noch ziemlich langsam
und ohne Auswertung der Farbinformation, immerhin ist schon was
zu sehen...

Version 0.0
Erste Basic-Version eines FLI-Analyzers ist fertig, in Anlehnung an
einen  Artikel in der c't 8/94, das Programm kann den Header auswerten
und sich durch die komplette Block-Struktur eines FLIs hangeln.

Sven Bruns

[EOF]